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Abstract. We present a computer-aided programming approach to con¬ 
currency. The approach allows programmers to program assuming a 
friendly, non-preemptive scheduler, and our synthesis procedure inserts 
synchronization to ensure that the final program works even with a pre¬ 
emptive scheduler. The correctness specification is implicit, inferred from 
the non-preemptive behavior. Let us consider sequences of calls that the 
program makes to an external interface. The specification requires that 
any such sequence produced under a preemptive scheduler should be in¬ 
cluded in the set of such sequences produced under a non-preemptive 
scheduler. The solution is based on a Unitary abstraction, an algorithm 
for bounded language inclusion modulo an independence relation, and 
rules for inserting synchronization. We apply the approach to device¬ 
driver programming, where the driver threads call the software interface 
of the device and the API provided by the operating system. Our exper¬ 
iments demonstrate that our synthesis method is precise and efficient, 
and, since it does not require explicit specifications, is more practical 
than the conventional approach based on user-provided assertions. 


1 Introduction 

Concurrent shared-memory programming is notoriously difficult and error-prone. 
Program synthesis for concurrency aims to mitigate this complexity by synthe¬ 
sizing synchronization code automatically 0100111]. However, specifying the 
programmer’s intent may be a challenge in itself. Declarative mechanisms, such 
as assertions, suffer from the drawback that it is difficult to ensure that the 
specification is complete and fully captures the programmer’s intent. 

We propose a solution where the specification is implicit. We observe that 
a core difficulty in concurrent programming originates from the fact that the 
scheduler can preempt the execution of a thread at any time. We therefore give 
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the developer the option to program assuming a friendly, non-preemptive, sched¬ 
uler. Our tool automatically synthesizes synchronization code to ensure that 
every behavior of the program under preemptive scheduling is included in the 
set of behaviors produced under non-preemptive scheduling. Thus, we use the 
non-preemptive semantics as an implicit correctness specification. 

The non-preemptive scheduling model dramatically simplifies the develop¬ 
ment of concurrent software, including operating system (OS) kernels, network 
servers, database systems, etc. pJl|T4]. In this model, a thread can only be de- 
scheduled by voluntarily yielding control, e.g., by invoking a blocking operation. 
Synchronization primitives may be used for communication between threads, 
e.g., a producer thread may use a semaphore to notify the consumer about 
availability of data. However, one does not need to worry about protecting ac¬ 
cesses to shared state: a series of memory accesses executes atomically as long 
as the scheduled thread does not yield. 

In defining behavioral equivalence between preemptive and non-preemptive 
executions, we focus on externally observable program behaviors: two program 
executions are observationally equivalent if they generate the same sequences of 
calls to interfaces of interest. This approach facilitates modular synthesis where a 
module’s behavior is characterized in terms of its interaction with other modules. 
Given a multi-threaded program C and a synthesized program C' obtained by 
adding synchronization to C, C is preemption-safe w.r.t. C if for each execution 
of C' under a preemptive scheduler, there is an observationally equivalent non- 
preemptive execution of C. Our synthesis goal is to automatically generate a 
preemption-safe version of the input program. 

We rely on abstraction to achieve efficient synthesis of multi-threaded pro¬ 
grams. We propose a simple, data-oblivious abstraction inspired by an analysis 
of synchronization patterns in OS code, which tend to be independent of data 
values. The abstraction tracks types of accesses (read or write) to each memory 
location while ignoring their values. In addition, the abstraction tracks branch¬ 
ing choices. Calls to an external interface are modeled as writes to a special 
memory location, with independent interfaces modeled as separate locations. To 
the best of our knowledge, our proposed abstraction is yet to be explored in the 
verification and synthesis literature. 

Two abstract program executions are observationally equivalent if they are 
equal modulo the classical independence relation I on memory accesses: accesses 
to different locations are independent, and accesses to the same location are 
independent iff they are both read accesses. Using this notion of equivalence, 
the notion of preemption-safety is extended to abstract programs. 

Under abstraction, we model each thread as a nondeterministic finite automa¬ 
ton (NFA) over a finite alphabet, with each symbol corresponding to a read or a 
write to a particular variable. This enables us to construct NFAs N, represent¬ 
ing the abstraction of the original program C under non-premptive scheduling, 
and P, representing the abstraction of the synthesized program C under pre¬ 
emptive scheduling. We show that preemption-safety of C w.r.t. C is implied 
by preemption-safety of the abstract synthesized program w.r.t. the abstract 
original program, which, in turn, is implied by language inclusion modulo / of 
NFAs P and N. While the problem of language inclusion modulo an indepen- 


dence relation is undecidable [2], we show that the antichain-based algorithm for 
standard language inclusion |9] can be adapted to decide a bounded version of 
language inclusion modulo an independence relation. 

Our overall synthesis procedure works as follows: we run the algorithm for 
bounded language inclusion modulo /, iteratively increasing the bound, until it 
reports that the inclusion holds, or finds a counterexample, or reaches a timeout. 
In the first case, the synthesis procedure terminates successfully. In the second 
case, the counterexample is generalized to a set of counterexamples represented 
as a Boolean combination of ordering constraints over control-flow locations 
(as in ed- These constraints are analyzed for patterns indicating the type of 
concurrency bug (atomicity, ordering violation) and the type of applicable fix 
(lock insertion, statement reordering). After applying the fix(es), the procedure 
is restarted from scratch; the process continues until we find a preemption-safe 
program, or reach a timeout. 

We implemented our synthesis procedure in a new prototype tool called LiSS 
(Language Inclusion-based Synchronization Synthesis) and evaluated it on a se¬ 
ries of device driver benchmarks, including an Ethernet driver for Linux and the 
synchronization skeleton of a USB-to-serial controller driver. First, LiSS was able 
to detect and eliminate all but two known race conditions in our examples; these 
included one race condition that we previously missed when synthesizing from 
explicit specifications [5], due to a missing assertion. Second, our abstraction 
proved highly efficient: LiSS runs an order of magnitude faster on the more com¬ 
plicated examples than our previous synthesis tool based on the CBMC model 
checker. Third, our coarse abstraction proved surprisingly precise in practice: 
across all our benchmarks, we only encountered three program locations where 
manual abstraction refinement was needed to avoid the generation of unneces¬ 
sary synchronization. Overall, our evaluation strongly supports the use of the 
implicit specification approach based on non-preemptive scheduling semantics 
as well as the use of the data-oblivious abstraction to achieve practical synthesis 
for real-world systems code. 

Contributions. First, we propose a new specification-free approach to synchro¬ 
nization synthesis. Given a program written assuming a friendly, non-preemptive 
scheduler, we automatically generate a preemption-safe version of the program. 
Second, we introduce a novel abstraction scheme and use it to reduce preemption- 
safety to language inclusion modulo an independence relation. Third, we present 
the first language inclusion-based synchronization synthesis procedure and tool 
for concurrent programs. Our synthesis procedure includes a new algorithm for 
a bounded version of our inherently undecidable language inclusion problem. 
Finally, we evaluate our synthesis procedure on several examples. To the best of 
our knowledge, LiSS is the first synthesis tool capable of handling realistic (al¬ 
beit simplified) device driver code, while previous tools were evaluated on small 
fragments of driver code or on manually extracted synchronization skeletons. 
Related work. Synthesis of synchronization is an active research area EHMnb 
mmm- Closest to our work is a recent paper by Bloem et al. [3], which uses 
implicit specifications for synchronization synthesis. While their specification is 
given by sequential behaviors, ours is given by non-preemptive behaviors. This 
makes our approach applicable to scenarios where threads need to communicate 



void open.devO { 

1: while (*) { 

2: if (open==0) { 

3: power _up(); 

4 : } 

5: open=open+l; 

6: yield; } } 


void close.devO { 

7: while (*) { 

8: if (open>0) { 

9: open=open-l; 

10: if (open==0) { 

11: power.down(); 

12 : } } 

13: yield; } } 


void open_dev_abs () { 
1: while (*) { 

2: (A) r open; 

if (*) { 

3: (B) w dev; 

4: } 

5: (C) r open; 

(D) w open; 

6: yield; } } 


void close_dev_abs 

7: 

while 

(*) { 

8: 

(E) r 

open; 


if (* 
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9: 
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r open; 
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w open; 
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r open; 
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(I) w dev; 
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} } 


13 

yield 
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Fig. 1: Running example and its abstraction 


explicitly. Further, correctness in [3] is determined by comparing values at the 
end of the execution. In contrast, we compare sequences of events, which serves 
as a more suitable specification for infinitely-looping reactive systems. 

Many efforts in synthesis of synchronization focus on user-provided specifi¬ 
cations, such as assertions (our previous work [3H5][TX] ). However, it is hard to 
determine if a given set of assertions represents a complete specification. In this 
paper, we are solving language inclusion, a computationally harder problem than 
reachability. However, due to our abstraction, our tool performs significantly bet¬ 
ter than tools from FTTPTI . which are based on a mature model checker (CBMC [7]). 
Our abstraction is reminiscent of previously used abstractions that track reads 
and writes to individual locations (e.g., mm)- However, our abstraction is novel 
as it additionally tracks some control-flow information (specifically, the branches 
taken) giving us higher precision with almost negligible computational cost. The 
synthesis part of our approach is based on la¬ 
in [16] the authors rely on assertions for synchronization synthesis and in¬ 
clude iterative abstraction refinement in their framework. This is an interesting 
extension to pursue for our abstraction. In other related work, CFix [12] can 
detect and fix concurrency bugs by identifying simple bug patterns in the code. 


2 Illustrative Example 

IFig- TJa, contains our running example. Consider the case where the procedures 
open_dev() and close_dev() are invoked in parallel, possibly multiple times 
(modeled as a non-deterministic while loop). The functions power_up() and 
power_down() represent calls to a device. For the non-preemptive scheduler, 
the sequence of calls to the device will always be a repeating sequence of one 
call to power_up(), followed by one call to power_down(). Without additional 
synchronization, however, there could be two calls to power_up() in a row when 
executing it with a preemptive scheduler. Such a sequence is not observationally 
equivalent to any sequence that can be produced when executing with a non- 
preemptive scheduler. 

|Fig. 1| 3 contains the abstracted versions (we omit tracking of branch¬ 
ing choices in the example)of the two procedures, open_dev_abs () and 
close_dev_abs(). For instance, the instruction open = open + 1 is abstracted 
to the two instructions labeled (C) and (D). The abstraction is coarse, but 
still captures the problem. Consider two threads T1 and T2 running the 
open_dev_abs () procedure. The following trace is possible under a preemp¬ 
tive scheduler, but not under a non-preemptive scheduler: Tl.A; T2.A; Tl.B; 













Tl.C; Tl.D; T2.B; T2.C; T2.D. Moreover, the trace cannot be transformed 
by swapping independent events into any trace possible under a non-preemptive 
scheduler. This is because instructions A and D are not independent. Hence, 
the abstract trace exhibits the problem of two successive calls to power_up() 
when executing with a preemptive scheduler. Our synthesis procedure finds this 
problem, and fixes it by introducing a lock in open_dev() (see Sec. 0. 

3 Preliminaries and Problem Statement 

Syntax. We assume that programs are written in a concurrent while language 
W. A concurrent program C in W is a finite collection of threads (Ti,... ,T„) 
where each thread is a statement written in the syntax from |Fig. 2| All W vari¬ 
ables (program variables std_var, lock variables lock_var, and condition vari¬ 
able cond_var) range over integers and each statement is labeled with a unique 
location identifier l. The only non-standard syntactic constructs in W relate to 
the tags. Intuitively, each tag is a communication channel between the program 
and an interface to an external system, and the input(tag) and output(tag, expr) 
statements read from and write to the channel. We assume that the program 
and the external system interface can only communicate through the channel. 
In practice, we use the tags to model device registers. In our presentation, we 
consider only a single external interface. Our implementation can handle com¬ 
munication with several interfaces. 

expr : : = std_var i constant i operator (expr, expr, ..., expr) * 

lstmt ::= loc: stmt I lstmt; lstmt 

stmt ::= skip I std_var := expr I std_var := havoc0 
I if (expr) lstmt else lstmt I while (expr) lstmt I std_var := input(tag) 

I output(tag, expr) I lock(lock_var) I unlock(lock_var) 

[ I signal(cond var) I await(cond var) I reset(cond var) I yield 

Fig. 2: Syntax of W 

Semantics. We begin by defining the semantics of a single thread in W, and then 
extend the definition to concurrent non-preemptive and preemptive semantics. 
Note that in our work, reads and writes are assumed to execute atomically and 
further, we assume a sequentially consistent memory model. 

Single-thread, semantics. A program state is given by (V, P) where V is a valua¬ 
tion of all program variables, and P is the statement that remains to be executed. 
Let us fix a thread identifier tid. 

The operational semantics of a thread executing in isolation is given in |Fig. 3] 
A single execution step (V, P) —*■ (V', P') changes the program state from (V, P) 
to (V', P') while optionally outputting an observable symbol a. The absence of 
a symbol is denoted using e. Most rules from |Fig. 3| are standard—the special 
rules are the Havoc, Input, and Output rules. 

1. HAVOC: Statement l: x := havoc assigns x a non-deterministic value (say k) 
and outputs the observable (tid, havoc, k, x). 

2. Input, Output: l: x := input(f) and l : output(f,e) read and write values to 
the channel t, and output (tid, input, k, t) and (tid, output, k, t), where k is 
the value read or written, respectively. 











Intuitively, the observables record the sequence of non-deterministic guesses, 
as well as the input/output interaction with the tagged channels. In the following, 
e represents an expression and e[u/V[e]] evaluates an expression by replacing 
all variables v with their values in V. 


e\vlV\v\\ = k fcsN a = f tid, havoc, k, x) 

-Assign - , ’ - ——-Havoc 


(V,l: x := e) —*■ (V[x := A:],skip) (V,Z : x := havoc) —>• (V\x := fc],skip) 


e[v/V[i)]] = false 


While 1 


e[v/V[v]] = true 


(V,l ■ while(e) s) —*■ (V, s; while(e) s) 


While2 


“If 1 


e[v/V[v]] = false 


(V, Z: while(e) s) —* (V,skip) 
e[v/V[t)]] = true 

(V, l : if e then si else S2) (V, si) (V,l : if e then si else S2) -* (V, S2) 

(V,si) (V',si) „ fceN a = (tid, input, k,t) 

-Sequence 777-7-;- a .... -——tttInput 


-If2 


(V,l: s 1 ;s 2 )^(V',s i;a 2 > 


(V,l ■■ skip; S2) -*■ (V,s 2 ) 


(V, l : x := input(t)) —> (V\x := /c], skip) 

ef-u/Vlvll = fc a = (tid, output, k, t) 

■Skip ----— a , --- Output 

(V, l : output(f,e)) —»• (V,skip) 


Fig. 3: Single thread semantics of W 


Non-preemptive semantics. The non-preemptive semantics of W is presented in 
Appendix [A] The non-preemptive semantics ensures that a single thread from 
the program keeps executing as detailed above until one of the following occurs: 
(a) the thread finishes execution, or it encounters (b) a yield statement, or (c) a 
lock statement and the lock is taken, or (d) an await statement and the condition 
variable is not set. In these cases, a context-switch is possible. 

Preemptive semantics. The preemptive semantics of a program is obtained from 
the non-preemptive semantics by relaxing the condition on context-switches, and 
allowing context-switches at all program points (see Appendix 0 . 


3.1 Problem statement 

A non-preemptive observation sequence of a program C is a sequence ao ■ ■ ■ otk if 
there exist program states S^ re , SQ OSt , ..., S^ re , S^ ost such that according to the 

non-preemptive semantics of W, we have: (a) for each 0 < * < fc, {Sf re ) —>■ {Sf° st ), 
(b) for each 0 < i < k, (Sf° st ) and (c) for the initial state S L and a 

final state (i.e., where all threads have finished execution) Sf, (S t ) -~+*(Sg re ) and 
impost) Similarly, a preemptive observation sequence of a program C is 

a sequence ao ...otk as above, with the non-preemptive semantics replaced with 
preemptive semantics. We denote the sets of non-preemptive and preemptive 
observation sequences of a program C by [[C]] Arp and [[C]] p , respectively. 

We say that observation sequences ao ...ak and /?o - - - are equivalent if: 

— The subsequences of op ... ak and f3o ■ ■ ■ Pk containing only symbols of the 
form {tid, Input, k,t) and {tid, Output, k, t) are equal, and 

— For each thread identifier tid, the subsequences of op ... ak and j3o ■ ■ ■ Pk 
containing only symbols of the form {tid, Havoc, k, x) are equal. 

Intuitively, observable sequences are equivalent if they have the same interaction 
with the interface, and the same non-deterministic choices in each thread. For 














sets of observable sequences 0\ and 0 2 , we write (D\ £ O 2 to denote that each 
sequence in 0\ has an equivalent sequence in 0 2 - Given a concurrent program 
C and a synthesized program C obtained by adding synchronization to C, the 
program C is preemption-safe w.r.t. C if [[C']] p £ [[C]] iVf ’. 

We are now ready to state our synthesis problem. Given a concurrent program 
C, the aim is to synthesize a program C, by adding synchronization to C, such 
that C is preemption-safe w.r.t. C. 


3.2 Language Inclusion Modulo an Independence Relation 


We reduce the problem of checking if a synthesized solution is preemption-safe 
w.r.t. the original program to an automata-theoretic problem. 

Abstract semantics for W. We first define a single-thread abstract semantics 
for W ( |Fig. 4| ), which tracks types of accesses (read or write) to each memory 
location while abstracting away their values. Inputs/outputs to an external in¬ 
terface are modeled as writes to a special memory location (dev). Even inputs 
are modeled as writes because in our applications we cannot assume that reads 
from the external interface are free of side-effects. Havocs become ordinary writes 
to the variable they are assigned to. Every branch is taken non-deterministically 
and tracked. The only constructs preserved are the lock and condition variables. 
The abstract program state consists of the valuations of the lock and condition 
variables and the statement that remains to be executed. In the abstraction, 
an observable is of the form (tid, {read, write, exit, loop, then, else}, v, l) and ob¬ 
serves the type of access (read/write) to variable v and records non-deterministic 
branching choices (exit/loop/then/else). The latter are not associated with any 
variable. 

In |Fig. 4] given expression e, the function Reads (tid, e,l) represents the se¬ 
quence ( tid , read, v\ , l ) •... • ( tid , read, v n , l ) where v\,...,v n are the variables in 
e, in the order they are read to evaluate e. 


a = Reads(tid, e, l) ■ (tid, write, x, l) 
(V,Z : x := e) (V,skip) 
a = Reads(tid, e, l) ■ (tid, exit, l) 


■Assign 


a = (tid, write, x, l ) 

(V,l : x := havoc) -A- (V,skip) 


■Havoc 


(V, Z : while(e) s) —*■ (V,skip) 
a = Reads(tid, e, l ) ■ (tid, then, Z) 
(V ,l : if e then si else S2) (V, si) 

(V,si) —>■ (V',si) 


a = Reads (tid, e, l) ■ (tid, loop, Z) 

WhileI -—— , c , - ——-While2 


(V, Z : while(e) s) —► (V, s; while(e) s) 
a = Reads(tid, e, l ) ■ (tid, else, Z) 

(V,Z : if e then si else S2) (V, S2) 


<V,Z: S 1 ; S 2 )^(V', S ' 1;S2 ) 


a = (tid, write, dev, Z) ■ (tid, write, x, l) 

■Sequence ---:- ... a , , . , -Input 

(Z : x := input(t)) —> (skip) 


(V,Z : skip; S2 ) -* ( V, S2) 


a = Reads(tid, e, Z) • (tid, write, dev, Z) 

Skip ----— w a , --—;-Output 

(V,Z: output(Z,e)) —*• (V,skip) 


Fig. 4: Single thread abstract semantics of W 
The abstract program semantics (Figures |5] and 0 is the same as the concrete 
program semantics where the single thread semantics is replaced by the abstract 


















single thread semantics. Locks and conditionals and operations on them are not 
abstracted. 

As with the concrete semantics of W, we can define the non-preemptive and 
preemptive observable sequences for abstract semantics. For a concurrent pro¬ 
gram C, we denote the sets of abstract preemptive and non-preemptive observable 
sequences by [[CJf &s and [[C]]f fc f, respectively. 

Abstract observation sequences op ... au and fio ■ ■ • Pk are equivalent if: 

— For each thread tid , the subsequences of ao ■ ■ - CXk and /?o ■ • ■ /Jfc 
containing only symbols of the form ( tid, a, v, l ), with a e 
{read, write, exit, loop, then, else} are equal, 

— For each variable v, the subsequences of an ■ • • o-k and /?o ■ ■ • fa containing 
only write symbols (of the form (tid, write, v ,/)) are equal, and 

— For each variable v, the multisets of symbols of the form (tid, read ,v,l) be¬ 
tween any two write symbols, as well as before the first write symbol and 
after the last write symbol are identical. 

We first show that the abstract semantics is sound w.r.t. preemption-safety (see 
Appendix iBl for the proof). 

Theorem 1. Given concurrent program C and a synthesized program C' ob¬ 
tained by adding synchronization to C, => [[C , ]] P £ [[C]] JVP . 

Abstract semantics to automata. An NFA A is a tuple (Q,E,A,Q L ,F) 
where A is a finite alphabet, Q,Q L ,F are finite sets of states, initial states and 
final states, respectively and A is a set of transitions. A word ao . . . a/- e At* is 
accepted by A if there exists a sequence of states go ■ ■ • gfc+i such that go e Q L and 
gfc+i € F and Vi : (g,, ag, g i+ i) e A. The set of all words accepted by A is called 
the language of A and is denoted £(A). 

Given a program C, we can construct automata ^([[C]]^^ ) and A([[CJf bs ) 
that accept exactly the observable sequences under the respective semantics. 
We describe their construction informally. Each automaton state is a program 
state of the abstract semantics and the alphabet is the set of abstract observable 
symbols. There is a transition from one state to another on an observable symbol 
(or an e) iff the program can execute one step under the corresponding semantics 
to reach the other state while outputting the observable symbol (on an e). 
Language inclusion modulo an independence relation. Let / be a non¬ 
reflexive, symmetric binary relation over an alphabet E. We refer to I as the 
independence relation and to elements of / as independent symbol pairs. We 
define a symmetric binary relation r; over words in E*: for all words a, a' e E* 
and (a, (3) el, (a ■ a(3 ■ a', a ■ /3a • a') €rj. Let A denote the reflexive transitive 
closure of Given a language C over E, the closure of C w.r.t. I, denoted 
Ck>/(£), is the set {a e E*: 3a' e £ with (a, a') e A}. Thus, Clo/(£) consists of 
all words that can be obtained from some word in £ by repeatedly commuting 
adjacent independent symbol pairs from I. 

Definition 1 (Language inclusion modulo an independence relation). 

Given NFAs A, B over a common alphabet E and an independence relation I 
over E, the language inclusion problem modulo I is: £(A) £ Clo i(£(B))? 


5 The equivalence classes of are Mazurkiewicz traces. 



We reduce preemption-safety under the abstract semantics to language 
inclusion modulo an independence relation. The independence relation / 
we use is defined on the set of abstract observable symbols as follows: 
((tid,a,v,l),(tid',a',v',l')) e / iff tid + tid', and one of the following holds: 
(a) v + v' or (b) a + write a a' + write. 

Proposition 1. Given concurrent programs C and C , [[C']]^ s £ mi p s iff 
£McX bs )) £ cio/(£(yl([[C]]f 6 f))). 

4 Checking Language Inclusion 

We first focus on the problem of language inclusion modulo an independence 
relation (Definition [[]). This question corresponds to preemption-safety (Thm.|T| 
Prop.Q} and its solution drives our synchronization synthesis (Sec. [5]). 

Theorem 2. For NFAs A,B over alphabet E and an independence relation I £ 
E x E, C{A) £ Clo/(£(f?)) is undecidable 

Fortunately, a bounded version of the problem is decidable. Recall the rela¬ 
tion « over E* from Sec. 13.21 We define a symmetric binary relation r q over E*: 
(cr,cr') e r q iff 3(a, /3) e I: (cr,cr') e rs, cr[*] = a'[i + 1] = a and cr[i + 1] = a'[i] = /3. 
Thus Ri* consists of all words that can be optained from each other by commut¬ 
ing the symbols at positions i and i + 1. We next define a symmetric binary 
relation x over E*: (cr, cr') e x iff Boy,..., cr t : (cr, oy) e ..., (cr t , cr') e Ry t+1 and 
ii < ... < it+i- The relation x intuitively consists of words obtained from each 
other by making a single forward pass commuting multiple pairs of adjacent 
symbols. Let x fe denote the fc-composition of x with itself. Given a language C 
over E , we use Clofcy(£) to denote the set {cr e E* : 3cr' e C with (a, a') ex fc ). 
In other words, Clo k,i(£) consists of all words which can be generated from C 
using a finite-state transducer that remembers at most k symbols of its input 
words in its states. 

Definition 2 (Bounded language inclusion modulo an independence 
relation). Given NFAs A,B over E, I £ E x E and a constant k > 0, the 
k-bounded language inclusion problem modulo I is: C(A) £ Clo k,i{C,{B))? 

Theorem 3. For NFAs A,B over E, I £ E x E and a constant k > 0, C{A) £ 
Clofcj(£(R)) is decidable. 

We present an algorithm to check fc-bounded language inclusion modulo /, 
based on the antichain algorithm for standard language inclusion [5]. 
Antichain algorithm for language inclusion. Given a partial order (A, e), 
an antichain over X is a set of elements of X that are incomparable w.r.t. E. 
In order to check C{A) £ Clo j(C(B)) for NFAs A = (Qa,E,Aa,Ql,a,Fa) and 
B - (Qb, E , Ab,Ql.b, Fb), the antichain algorithm proceeds by exploring A 
and B in lockstep. While A is explored nondeterministically, B is determinized 
on the fly for exploration. The algorithm maintains an antichain, consisting of 
tuples of the form ( sa , Sb ), where sa e <5,4 and Sb £ Qb- The ordering relation 


£ is given by (sa,S b ) - (s'a^'b) S A = s' A and Sb £ S' B . The algorithm also 
maintains a frontier set of tuples yet to be explored. 

Given state s,4 e Qa and a symbol a e U, let succ a (sA) denote {s^ € Qa ■ 
(sa,oi,s' a ) e Aa}- Given set of states Sb £ Qb , let succ a (S B ) denote {s' B e 
Qb '■ 3 sb e Sb ■ (s B ,a,s' B ) e As}- Given tuple ( sa,Sb ) in the frontier set, let 
succ a (sA, S B ) denote {( s' A ,S B ): s' A e succ a (sA), S' b - succ a (s B )}. 

In each step, the antichain algorithm explores A and B by computing a- 
successors of all tuples in its current frontier set for all possible symbols a € S. 
Whenever a tuple (sa,S b ) is found with e Fa and Sb n F B = 0, the algo¬ 
rithm reports a counterexample to language inclusion. Otherwise, the algorithm 
updates its frontier set and antichain to include the newly computed successors 
using the two rules enumerated below. Given a newly computed successor tuple 

p': 

— Rule 1 : if there exists a tuple p in the antichain with p E p\ then p' is not 
added to the frontier set or antichain, 

— Rule 2 : else, if there exist tuples pi,...,p n in the antichain with p' E 
Pi ,... ,p n , then pi ,... ,p n are removed from the antichain. 

The algorithm terminates by either reporting a counterexample, or by declaring 
success when the frontier becomes empty. 

Antichain algorithm for fc-bounded language inclusion modulo I. This 
algorithm is essentially the same as the standard antichain algorithm, with the 
automaton B above replaced by an automaton B k j accepting Ck>fc,/(£(B)). The 
set Qs k j of states of B k j consists of triples (s Bl 771,772 ), where Sb e Qb and 771,772 
are fc-length words over E. Intuitively, the words 771 and 772 store symbols that 
are expected to be matched later along a run. The set of initial states of B k j is 
{(sb,0, 0 ) : sb e Ib}- The set of final states of B k j is {(sb,0, 0) : sb e F B }. 
The transition relation A Bk r is constructed by repeatedly applying the following 
rules, in order, for each state (s_b, 771,772) and each symbol a. In what follows, 
77[\j] denotes the word obtained from 77 by removing its i th symbol. 

1 . Pick new s' B and j 3 € E such that ( s B ,/ 3 ,s ' B ) e A B 

2 . (a) If Vi: ?7i[i] * a and a is independent of all symbols in 771, 

772 := 772 • ot and r][ := 771, (b) else, if 3 i: 771 [7] = a and a is independent of all 
symbols in 771 prior to i, :=?7i[m] and r ]' 2 := 772 (c) else, go to 1 

3 . (a) If Vi: 772[i] V /3 and (3 is independent of all symbols in r]' 2 , 

Vi '/?> (b) else, if 3 i: r ] 2 [i] = j 3 and /? is independent of all symbols in r ) 2 
prior to i, 772 := 772 ["^i] (c) else, go to 1 

4 . Add ((sb, 771,772), a, (s' B , 77^,772)) to A Bk I and go to 1 . 

Example 1 . In Fig .0 we have an NFA B with £(B) = {aj 3 ,j 3 }, I - {(a,/?)} and 
k = 1 . The states of B k j are triples ( q , 771,772), where q s Q B and 771,772 e {0, a, j 3 }. 
We explain the derivation of a couple of transitions of B k j- The transition shown 
in bold from (<70,0,0) on symbol /3 is obtained by applying the following rules 
once: 1 . Pick <71 since (<70, a, q±) e A B . 2 (a). if 2 := /?, ?7( := 0. 3 (a). 77^ := a. 4 . Add 
((go, 0 ,0),/ 3 , (< 7 i,o,/ 3 )) to A Bh I . The transition shown in bold from (771,0;,/?) 
on symbol a is obtained as follows: 1 . Pick q 2 since (qi,( 3 ,q 2 ) 6 A B . 2 (b). := 0, 

77/, := /?. 3 (b). 772 := 0. 4 . Add ((qi,a, /?),/?, (<72,0,0)) to A BkI - It can be seen 
that B k j accepts the language {o/?,/ 3 o,/?} = Clofcj(I?). 



Fig. 5 : Example for illustrating construction of B^j for k = 1 and I = {(a,/ 3 )}. 
Proposition 2 . Given k > 0 , NFA Bkj described above accepts Clo k,i(C(B)). 

We develop a procedure to check language inclusion modulo / by iteratively 
increasing the bound k (see Appendix [C] for the complete algorithm). The proce¬ 
dure is incremental: the check for /c+l-bounded language inclusion modulo I only 
explores paths along which the bound k was exceeded in the previous iteration. 

5 Synchronization Synthesis 

We now present our iterative synchronization synthesis procedure, which is based 
on the procedure in m- The reader is referred to m for further details. The 
synthesis procedure starts with the original program C and in each iteration 
generates a candidate synthesized program C. The candidate C is checked for 
preemption-safety w.r.t. C under the abstract semantics, using our procedure for 
bounded language inclusion modulo I. If C' is found preemption-safe w.r.t. C 
under the abstract semantics, the synthesis procedure outputs C. Otherwise, an 
abstract counterexample cex is obtained. The counterexample is analyzed to in¬ 
fer additional synchronization to be added to C for generating a new synthesized 
candidate. 

The counterexample trace cex is a sequence of event identifiers: 
tido-lo ;...; tid n .l n , where each li is a location identifier. We first analyze the 
neighborhood of cex, denoted nhood(cex), consisting of traces that are permu¬ 
tations of the events in cea;. Note that each trace corresponds to an abstract 
observation sequence. Furthermore, note that preemption-safety requires the 
abstract observation sequence of any trace in nhood(cex) to be equivalent to 
that of some trace in nhood(cex) feasible under non-preemptive semantics. Let 
bad traces refer to the traces in nhood(cex) that are feasible under preemptive 
semantics and do not meet the preemption-safety requirement. The goal of our 
counterexample analysis is to characterize all bad traces in nhood{cex) in order 
to enable inference of synchronization fixes. 

In order to succinctly represent subsets of nhood(cex), we use ordering con¬ 
straints. Intuitively, ordering constraints are of the following forms: (a) atomic 
constraints <P = A < B where A and B are events from cex. The constraint A < B 
represents the set of traces in nhood(cex) where event A is scheduled before 
event B\ (b) Boolean combinations of atomic constraints d>i a<£ 2 , d>\ v <? 2 and 

. We have that d>i a <£ 2 and d>i v <d > 2 respectively represent the intersection 
and union of the set of traces represented by <P± and <£ 2 , and that represents 
the complement (with respect to nhood(cex)) of the traces represented by <P±. 





Non-preemptive neighborhood. First, we generate all traces in nhood(cex) 
that are feasible under non-preemptive semantics. We represent a single trace 
7T using an ordering constraint that captures the ordering between non- 
independent accesses to variables in n. We represent all traces in nhood(cex) 
that are feasible under non-preemptive semantics using the expression E = E v . 
The expression E acts as the correctness specification for traces in nhood(cex). 
Example. Recall the counterexample trace from the running ex¬ 
ample in Sec. [2] cex = Tl.A; T2.A; Tl.B; Tl.C; Tl.D; T2.B; T2.C; T2.D. 
There are two trace in nhood{cex) that are feasible under non- 
preemptive semantics: 7Ti = Tl.A; Tl.B; Tl.C; Tl.D; T2.A; T2.B; T2.C; T2.D 
and 7T2 = T2.A;T2.B; T2.C; T2.D; Tl.A; Tl.B; Tl.C; Tl.D. We represent 7Ti as 

<P(m) = {Tl.A,Tl.C,Tl.D} < T2.D A Tl.D < {T2.A,T2.C,T2.D} A Tl.B < T2.B and 
tt 2 as E(i r 2 ) = T2.D < {Tl.A,Tl.C,Tl.D} A {T2.A,T2.C,T2.D} < Tl.D A T2.B < Tl.B. 
The correctness specification is E = E(ni) v <£(7t 2 ). 

Counterexample generalization. We next build a quantifier-free first order 
formula E over the event identifiers in cex such that any model of E corresponds 
to a bad trace in nhood(cex). We iteratively enumerate models n of E , building a 
constraint p = E(ir) for each model 7r, and generalizing each p into p g to represent 
a larger set of bad traces. 

Example. Our trace cex from Sec. [2] would be generalized to T2.A < Tl.D a Tl.D < 
T2.D. Any trace that fulfills this constraint is bad. 

Inferring fixes. From each generalized formula p g described above, we infer 
possible synchronization fixes to eliminate all bad traces satisfying p g . The key 
observation we exploit is that common concurrency bugs often show up in our 
formulas as simple patterns of ordering constraints between events. For example, 
the pattern tid\.l\ < tid- 2 -l 2 A tid 2 -l '2 < tidi.l[ indicates an atomicity violation 
and can be rewritten into lock(fidi.[7i : Z}],fid 2 .[7 2 : ^ 2 ]). The complete list of 
such rewrite rules is in Appendix [D] This list includes inference of locks and 
reordering of notify statements. The set of patterns we use for synchronization 
inference are not complete, i.e., there might be generalized formulae p g that are 
not matched by any pattern. In practice, we found our current set of patterns 
to be adequate for most common concurrency bugs, including all bugs from the 
benchmarks in this paper. Our technique and tool can be easily extended with 
new patterns. 

Example. The generalized constraint T2.A < Tl.D a Tl.D < T2.D matches the lock 
rule and yields lock(T2.[A: D],T1.[D : D]). Since the lock involves events in the 
same function, the lock is merged into a single lock around instructions A and D in 
open_dev_abs. This lock is not sufficient to make the program preemption-safe. 
Another iteration of the synthesis procedure generates another counterexample 
for analysis and synchronization inference. 

Proposition 3. If our synthesis procedure generates a program C', then C' is 
preemption-safe with respect to C. 


Note that our procedure does not guarantee that the synthesized program C 
is deadlock-free. However, we avoid obvious deadlocks using heursitics such as 
merging overlapping locks. Further, our tool supports detection of any additional 
deadlocks introduced by synthesis, but relies on the user to fix them. 


6 Implementation and Evaluation 


We implemented our synthesis procedure in LiSS. LiSS is comprised 
of 5000 lines of C++ code and uses Clang/LLVM and Z3 as li¬ 
braries. It is available as open-source software along with bench¬ 
marks at https://github.com/thorstent/Liss. The language in¬ 

clusion algorithm is available separately as a library called Limi 
(https://github.com/thorstent/Limi). LiSS implements the synthesis 
method presented in this paper with several optimizations. For example, we 
take advantage of the fact that language inclusion violations can often be de¬ 
tected by exploring only a small fraction of the input automata by constructing 
) and A{lCY abs ) on the fly. 

Our prototype implementation has several limitations. First, LiSS uses func¬ 
tion inlining and therefore cannot handle recursive programs. Second, we do not 
implement any form of alias analysis, which can lead to unsound abstractions. 
For example, we abstract statements of the form “*x = 0” as writes to variable 
x, while in reality other variables can be affected due to pointer aliasing. We 
sidestep this issue by manually massaging input programs to eliminate aliasing. 

Finally, LiSS implements a simplistic lock insertion strategy. Inference rules 
in Figure|8]produce locks expressed as sets of instructions that should be inside a 
lock. Placing the actual lock and unlock instructions in the C code is challenging 
because the instructions in the trace may span several basic blocks or even 
functions. We follow a structural approach where we find the innermost common 
parent block for the first and last instructions of the lock and place the lock and 
unlock instruction there. This does not work if the code has gotos or returns 
that could cause control to jump over the unlock statement. At the moment, we 
simply report such situations to the user. 

We evaluate our synthesis method against the following criteria: (1) Effec¬ 
tiveness of synthesis from implicit specifications; (2) Efficiency of the proposed 
synthesis procedure; (3) Precision of the proposed coarse abstraction scheme on 
real-world programs. 

Implicit vs explicit synthesis In order to evaluate the effectiveness of syn¬ 
thesis from implicit specifications, we apply LiSS to the set of benchmarks used 
in our previous ConRepair tool for assertion-based synthesis J5j. In addition, 
we evaluate LiSS and ConRepair on several new assertion-based benchmarks 
(Table [Q) ■ The set includes microbenchmarks modeling typical concurrency bug 
patterns in Linux drivers and the usb-serial macrobenchmark, which mod¬ 
els a complete synchronization skeleton of the USB-to-serial adapter driver. We 
preprocess these benchmarks by eliminating assertions used as explicit specifi¬ 
cations for synthesis. In addition, we replace statements of the form assume (v) 
with await (v), redeclaring all variables v used in such statements as condi¬ 
tion variables. This is necessary as our program syntax does not include assume 
statements. 

We use LiSS to synthesize a preemption-safe version of each benchmark. 
This method is based on the assumption that the benchmark is correct under 
non-preemptive scheduling and bugs can only arise due to preemptive schedul¬ 
ing. We discovered two benchmarks (lc-rc.c and myrilOge.c) that violated 


Name 


||LOC |Th |It |MB |BF(s) |Syn(s) |Ver(s) ||CR(s) 
ConRepair benchmarks [5] 


exl.c 

18 

2 

1 

1 

< Is 

< Is 

< Is 

< Is 

ex2.c 

23 

2 

1 

1 

< Is 

< Is 

< Is 

< Is 

ex3.c 

37 

2 

1 

1 

<ls 

<ls 

<ls 

<ls 

ex5.c 

42 

2 

3 

1 

<ls 

<ls 

2s 

<ls 

lc-rc.c 

35 

4 

0 

1 

- 

- 

<ls 

9s 

dvl394.c 

37 

2 

1 

1 

< Is 

< Is 

< Is 

17s 

em28xx.c 

20 

2 

1 

1 

< Is 

< Is 

< Is 

< Is 

f_acm.c 

80 

3 

1 

1 

< Is 

< Is 

< Is 

1871.99s 

i915 jrq.c 

17 

2 

1 

1 

< Is 

< Is 

< Is 

2.6s 

ipath.c 

23 

2 

1 

1 

<ls 

<ls 

<ls 

12s 

iwl3945.c 

26 

3 

1 

1 

<ls 

<ls 

<ls 

5s 

md.c 

35 

2 

1 

1 

<ls 

<ls 

<ls 

1.5s 

myrilOge.c 

60 

4 

2 

1 

- 

- 

< Is 

1.5s 

usb-serial.bugl.c 

357 

7 

2 

1 

0.4s 

3.1s 

3.4s 

oo b 

usb-serial.bug2.c 

355 

7 

1 

3 

0.7s 

2.1s 

12.9s 

3563s 

usb-serial.bug3.c 

352 

7 

1 

4 

3.8s 

1.3s 

111.1s 

b 

OO 

usb-serial. bug4.c 

351 

7 

1 

4 

93.9s 

2.4s 

123.1s 

b 

OO 

usb-serial. c“ 

357 

7 

1 

4 

- 

- 

103.2s 

1200s 


CPMAC driver benchmark 


cpmac.bugl.c 

1275 

5 

1 

1 

1.3s 

113.4s 

21.9s 

- 

cpmac.bug2.c 

1275 

5 

1 

1 

3.3s 

68.4s 

27.8s 

- 

cpmac.bug3.c 

1270 

5 

1 

1 

5.4s 

111.3s 

8.7s 

- 

cpmac. bug4.c 

1276 

5 

2 

1 

2.4s 

124.8s 

31.5s 

- 

cpmac.bug5.c 

1275 

5 

1 

1 

2.8s 

112.0s 

58.0s 

- 

cpmac. c a 

545 c 

5 

1 

1 

- 

- 

17.4s 

- 


Th=Threads, It=Iterations, MB=Max bound, BF=Bug finding, Syn=Synthesis, 

Ver=Verification, Cr=CONREPAiR “ bug-free example 6 timeout after 3 hours 

Table 1: Experiments 

this assumption, i.e., they contained race conditions that manifested under non- 
preemptive scheduling; LiSS did not detect these race conditions. LiSS was able 
to detect and fix all other known races without relying on assertions. Further¬ 
more, LiSS detected a new race in the usb-serial family of benchmarks, which 
was not detected by ConRepair due to a missing assertion. We compared the 
output of LiSS with manually placed synchronization (taken from real bug fixes) 
and found that the two versions were similar in most of our examples. 

Performance and precision. ConRepair uses CBMC for verification and 
counterexample generation. Due to the coarse abstraction we use, both steps are 
much cheaper with LiSS. For example, verification of usb-serial . c, which was 
the most complex in our set of benchmarks, took LiSS 82 seconds, whereas it 
took ConRepair 20 minutes [5]. 

The loss of precision due to abstraction may cause the inclusion check to 
return a counterexample that is spurious in the concrete program, leading to 
unnecessary synchronization being synthesized. On our existing benchmarks, 
this only occurred once in the usb-serial driver, where abstracting away the 
return value of a function led to an infeasible trace. We refined the abstraction 
manually by introducing a condition variable to model the return value. 


























While this result is encouraging, synthetic benchmarks are not necessarily 
representative of real-world performance. We therefore implemented another set 
of benchmarks based on a complete Linux driver for the TI AR7 CPMAC Ether¬ 
net controller. The benchmark was constructed as follows. We manually prepro¬ 
cessed driver source code to eliminate pointer aliasing. We combined the driver 
with a model of the OS API and the software interface of the device written in 
C. We modeled most OS API functions as writes to a special memory location. 
Groups of unrelated functions were modeled using separate locations. Slightly 
more complex models were required for API functions that affect thread synchro¬ 
nization. For example, the free_irq function, which disables the driver’s inter¬ 
rupt handler, blocks waiting for any outstanding interrupts to finish. Drivers can 
rely on this behavior to avoid races. We introduced a condition variable to model 
this synchronization. Similarly, most device accesses were modeled as writes to 
a special ioval variable. Thus, the only part of the device that required a more 
accurate model was its interrupt enabling logic, which affects the behavior of 
the driver’s interrupt handler thread. 

Our original model consisted of eight threads. LiSS ran out of memory on 
this model, so we simplified it to five threads by eliminating parts of driver 
functionality. Nevertheless, we believe that the resulting model represents the 
most complex synchronization synthesis case study, based on real-world code, 
reported in the literature. 

The CPMAC driver used in this case study did not contain any known con¬ 
currency bugs, so we artificially simulated five typical race conditions that com¬ 
monly occur in drivers of this type j4] . LiSS was able to detect and automatically 
fix each of these defects (bottom part of Table [1|). We only encountered two pro¬ 
gram locations where manual abstraction refinement was necessary. 

We conclude that (1) our coarse abstraction is highly precise in practice; 
(2) manual effort involved in synchronization synthesis can be further reduced 
via automatic abstraction refinement; (3) additional work is required to improve 
the performance of our method to be able to handle real-world systems without 
simplification. In particular, our analysis indicates that significant speed-up can 
be obtained by incorporating a partial order reduction scheme into the language 
inclusion algorithm. 

7 Conclusion 

We believe our approach and the encouraging experimental results open several 
directions for future research. Combining the abstraction refinement, verification 
(checking language inclusion modulo an independence relation), and synthesis 
(inserting synchronization) more tightly could bring improvements in efficiency. 
An additional direction we plan on exploring is automated handling of deadlocks, 
i.e., extending our technique to automatically synthesize deadlock-free programs. 
Finally, we plan to further develop our prototype tool and apply it to other 
domains of concurrent systems code. 
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A Semantics of preemptive and non-preemptive 
execution 

In Fig. [G] we present the non-preemptive semantics. The preemptive semantics 
consist of the rules of the non-preemptive semantics and the single rule in Fig. [TJ 
We denote the state of a program as (V, did, (Pi,..., P n )) where (a) Valua¬ 
tion V is a valuation of all program variables. Further, for each lock l, we have 
that V[Z] holds the identifier of the thread that currently holds the lock, or 0 
if no thread holds the lock. Similarly, for a condition variable c, we have that 
V[c] =0 if the variable is reset and V[c] = 1 otherwise, (b) The value did is the 
thread identifier of the current executing thread or 0 in the initial state, and 
(c) Program fragments P\ to P n are the parts of the program to be executed by 
Ti to T„, respectively. 

The premise in rule Sequential refers to the single-threaded semantics in 
Fig.[3]or the abstract single-threaded semantics in Fig. 2) Rules LockYield and 
Await Yield force a context-switch iff the lock is not available or the condition 
variable is not set. 


did = 0 1 < did < n 

- --- g -:-—SCHEDULESTART 

(V,did, (Pi,... ,P n )) -*■ (V, did , (Pi,..., P„)) 

_ did = i (V,P,)^(V',P[) _Sequential 

(V,did,(Pi,...,P i ,...,P n ))^(V,did,(Pi,... i Pl,...,P n )) 

did = i V(l) i {0,i} 1 <did'<n 

_ v L r i ’ > _Lock Yield 

(V,did, (Pi,, lock (Z), ...,P n ))^ (V,did', (Pi,..., lock(J), •.., P n )> 

did = i V(Z)€{0,i} 

(V,did, (Pi,..., lock(i),..., P„)) A- (V[i := i],ctid, (Pi,... ,skip,..., P n )) 
did = i V(/) = did 

(V, did, (Pi,..., unlock(Z), ...,P n ))->- (V[Z := 0 ],did, (Pi ,..., skip ,... ,P n )) 
did = i V(c) = false 1 < did' < n 

- --- — e , - —AwaitYield 

(V,did, (Pi ,..., await (c), ...,P„))-> (V,did, (Pi,... ,await(c ),... ,P n )) 

did = i V(c) = true 

(V,did, (Pi ,..., await(c),..., P n )) ->■ (V,did, (Pi ,..., skip ,... ,P n )) 

did = i 

(V, did, (Pi,..., signal(c), ...,P n ))^* (V[c := true],cfid, (Pi,..., skip ,... ,P n )) 

did = i 

■ - .. Preset 

(V,did, (Pi,. ■ ■, reset (c),... , P„)) — <■ (V[c := false], did, (Pi, ..., skip,... , P„)) 

si + skip (V, did, (Pi,... ,si,... ,P n )) (V,cfirf,(Pi,... ,s'i,...,Pn)) s ence 

(V, did, (Pi,... ,si;s 2 , ■ ■ ■, Pn)) ^ (V,did, (Pi,. ■ ■ ,s'i;s 2 ,... ,P n )) 

did = i 1 < did' <n Pi = skip 

---- e , -;- —DescheduleSkip 

(V, did, (Pi,..., Pi,..., Pn)) ^ (V, did', (Pi,..., Pi,..., P n )) 

did = i 1 < did' < n 


-SlGNAL 


-Reset 


-DescheduleSkip 


(V, did, (Pi ,..., yield,... ,P n )) (V,did', (Pi ,..., skip ,... ,P n )) 


-Yield 


Fig. 6: Operational non-preemptive semantics 




1 < did' < n 

(V, did, (Pi,... ,P n )) ->■ (V, did', (Pi,..., P„)) 


■DeschedulePreempt 


Fig. 7: From non-preemptive semantics to preemptive semantics 


B Proof of Thm. |T] 

Theorem 1. Given concurrent program C and a synthesized program C' ob¬ 
tained by adding synchronization to C, [[C , ]] P bs £ [[CJ]^ => [[C']] p £ [[C]]^ 13 . 

Proof. Let us assume [[C']]f bs £ 

Let a' be a concrete observation sequence in [[C']] p . Let a' abs be the abstract 
observation sequence in corresponding to a'. Then, there exists cr a b s e 

m N ab p s such that a a bs is equivalent to <j' abs . 

Observe that if two abstract observation sequences — cj' abs from [[C']] p bs and 
cr a b s from are equivalent, then they correspond to executions over 

the same observable control-flow paths with the same data-flow into havoc and 
input/output statements. Hence, a' abs and <j a bs either both map back to infeasible 
concrete observation sequences, or both map back to feasible, equivalent concrete 
observation sequences. 

Since a' abs maps back to a feasible concrete observation sequence a' by def¬ 
inition, (7 a b a also maps back to a feasible concrete observation sequence, say er, 
such that er is equivalent to a'. Hence, we have [[C']] p £ [[C]] Arp . □ 





C Language Inclusion Procedure 


The algorithm for fc-bounded language inclusion modulo I is presented as func¬ 
tion INCLUSION in Algo. [T] (ignore Lines I771I751 for now) . The function proceeds 
exactly as the standard antichain algorithm outlined earlier. It explores A non- 
deterministically as before, and B^j is determinized on the fly for exploration. 
The antichain and frontier sets consist of tuples of the form (sa, SB kA ), where 
sa e Qa and Ss kA £ Qb x £ k x S k . Each tuple in the frontier set is first checked 
for equivalence w.r.t. acceptance (Line [18]). If this check fails, the function re¬ 
ports language inclusion failure (Line[lH]). If this check succeeds, the successors 
are computed (Line (2H]) - If a successor satisfies Rule 1, it is ignored (Tine I2T1). 
otherwise it is added to the frontier (Tine 1761) and the antichain (Line [271) . During 
the update of the antichain the algorithm ensures that its invariant is preserved 
according to rule 2. The frontier also stores a sequence of symbols that lead to a 
particular tuple of states in order to return a counterexample trace if language 
inclusion fails. 

We develop a procedure to check language inclusion modulo I by iteratively 
increasing the bound k (see Algo.[Qin the appendix). The procedure is incremen¬ 
tal: the check for k + 1-bounded language inclusion modulo I only explores paths 
along which the bound k was exceeded in the previous iteration. Given a newly 
computed successor (s' A ,S' Bki ) for an iteration with bound k , if there exists 
some (sb,i 71 , 772 ) in S' B , such that the length of 771 or 772 exceeds k (Line [22]), 
we remember the tuple ( s' A ,S B ) in the set overflow (Tine [751) . We continue 
exploration of Bkj from all states ( s_b, 771,772 ) with \rft\ < k /\ ( 772 ! < k, but mark 
them dirty. If we find a counter-example to language inclusion we return it and 
test if it is spurious (Line [8]). It may be a spurious counter-example caused be¬ 
cause we removed states exceeding k. In that case we increase the bound to k + 1, 
remove all dirty items from the antichain and frontier (lines 11011111) , and add the 
items from the overflow (Line 1121) . Intuitively this will undo all exploration from 
the point (s) the bound was exceeded and restarts from that/those point (s). 

To test if a particular counterexample is spurious, we invoke the language 
inclusion procedure, replacing the preemptive automaton with the exact trace 
(trace automaton) and allowing an infinite bound. This is fast and guaranteed 
to terminate as the trace automaton does not have loops. We found that this 
optimization helps find a valid counterexample faster. 




Algorithm 1 Checking language inclusion modulo I 

Require: Automata A = (Qa, Fa, Aa, Ia, Fa) and B = (Q B ,F B ,A B ,I B ,F B ) 

Ensure: true only if C{A) £ Clo false only if £}A) Clo i(C(B)) 

1: frontier «- {(sa, {(/b,0,0)},0) : sa e Ia} 

2: All tuples in frontier are not dirty 
3: antichain *- frontier 
4: overflow «- 0 
5: k *- 2 

6: while true do 
7: cea: <-iNCLUSlON(fc) 

8 : if cex true A cex is spurious then 

9: k *- k + 1 

10: frontier «- {(sa, S Bk I ) e frontier : S Bk r not dirty} u overflow 

11: antichain «- {(sA,Ss fc 7 ) e antichain ■ S Bk j not dirty} u overflow 

12: overflow «- 0 

13: else 

14: return cea: 

15: function iNCLUSlON(fc) 

16: while frontier + 0 do 

17: remove a tuple ( SA,S Bk r ,cex ) from frontier 

18: if sa c Fa A (S Bk T n Fb) = 0 then return cea: 

19: for all a e X 1 do 

20: (sa, t ) <- succ a (s A ,S BkJ ) 

21: if 6 antichain : p E ( s'A,S' Bk T ) then > Rule 1 

22: if 3 (sb,??i,? 72 ) e S' Bk I : |pi| > fc v |p 2 | > fc then 

23: if S' Bk j not dirty then overflow *- overflow u {(s r A,S Bk f )} 

24: S' Bk l «- {(s B ,V i,V2) 6 S’ BkI : |r?i| < k A |p 2 | < k} 

25: Mark S 1 ^ 7 dirty 

26: frontier *- frontier u {( 5 ( 4 , S' Bk , cex ■ a)} 

27: antichain *- antichain\{p: S' Bk E p} u {(s^, S' Bk )} > Rule 2 

28: return true 





D Synchronization inference rules 

The inference rules are applied as rewrite rules to the formula p g obtained in 
Sec. [5] Each rule requires a certain subexpression in p g and rewrites it to a 
synchronization primitive. That means that a single p g could possibly be solved 
by one of several synchronization primitives. 

The two lock rules fix atomicity violations and the reorder rule fixes ordering 
violations. The Add.Lock rule captures a set of threads where thread 1 is 
descheduled at or after location l\ and thread 2 is scheduled at or before Q- 
Another context switch deschedules thread 2 at or after 1' 2 and schedules again 
thread 1 at or before l[. As this pattern is present in the generalized p g this 
context switch is necessary to make the trace bad. We can avoid this context 
switch by adding the lock from the conclusion. The Add.Lock2 rules captures 
the more general case where both, thread 2 interrupting thread 1 and thread 1 
interrupting thread 2, are bad traces. 

The Add.Reorder rule captures an ordering violation that can be fixed 
by moving a signalQ statement. Intuitively the awaitQ statement is signaled too 
early and thread 1 can start running in the preemptive semantics. In the non- 
preemptive semantics thread 2 keeps running after a signalQ statement until a 
preemption point is reached. 


p g = tidi.li < tid2-l' 2 A tid2-h < tidi.l'i A ip 
lock(£idi.[Zi : ZQ, tid 2 .[l 2 ■ I 2 ]) V ip 
p g = tidi.li < tid2.h A tid2.l' 2 < tidi.l'i A ip 


Add.Lock 


Add.Lock2 


lock(iieZi.[Zi : ZQ, tid 2 -[h ■ Zj>]) v V' 

p g = tidi.li < tid2-l 2 a ip 3tidi_.li, tid2-h '■ tidi.li < tidi.l'i 
tid 2 -l 2 < tid 2 .l '2 tidi.li = await(c) tid 2 .l 2 = signal(c) 

reorder( tid 2 ,l 2 , tid 2 .l'2) v ip 


Add. Reorder 


Fig. 8: Synchronization inference rules 





